Systematische Berücksichtigung von Abhängigkeitsbeziehungen bei Architekturentscheidungen

Architekturentscheidungen gehören zu den riskantesten Entscheidungen in großen Entwicklungsprojekten, da häufig nur unvollständige und unstrukturierte Informationen vorliegen. Gerade aufgrund der lückenhaft dokumentierten Abhängigkeitsbeziehungen steigen die mit einer Entscheidung verbundenen Risiken. Da ein Verfahren zur Erkennung und Berücksichtigung der Abhängigkeitsbeziehungen bei Architekturentscheidungen bislang fehlt, ist ein geeigneter Entscheidungsprozess zu entwickeln. Das Ziel ist es, die komplexen Abhängigkeitsbeziehungen trotz unvollständiger Informationsgrundlage sichtbar zu machen, im Detail zu analysieren und sie systematisch bei der Entscheidungsfindung zu berücksichtigen. 1 Notwendigkeit der Systematisierung der Entscheidungsfindung In langfristigen Großprojekten sind Architekturund Reengineering-Entscheidungen schwer zu treffen und mit erheblichen Risiken für den Auftraggeber verbunden, da Abhängigkeitsbeziehungen nur lückenhaft bekannt sind. Es ist daher ein Verfahren erforderlich, um die Abhängigkeitsbeziehungen sichtbar zu machen und sie systematisch und in der erforderlichen Tiefe bei der Entscheidungsfindung berücksichtigen zu können. Architekturentscheidungen in Großprojekten erfolgen unter speziellen Bedingungen, wie einer hohen Zahl von Entwicklern, räumlich getrennten Teilprojekten und paralleler Entwicklung von getrennten Versionen. Ein hoher Termindruck und eine Vielzahl an Veränderungen erschweren die Aufrechterhaltung einer vollständigen und konsistenten Dokumentation zur Ermittlung der Abhängigkeitsbeziehungen. Das Risiko von Fehlentscheidungen für das betroffene Unternehmen besteht in hohem Korrekturaufwand sowie hohen finanziellen Verlusten bei Ausfall eines geschäftskritischen Systems. Ein strukturiertes, systematisches Vorgehen bei der Entscheidungsfindung hilft, die Komplexität zu beherrschen und Fehler zu vermeiden. Im ersten Schritt eines solchen Vorgehens werden die Ziele und Rahmenbedingungen erhoben und strukturiert. Dabei sind Widersprüche und Konkurrenz-Beziehungen zwischen den Zielen aufzulösen. Danach werden vom Architekten Lösungsansätze zur Veränderung der Architektur zwecks Erfüllung der Ziele entwickelt. Im Fall existierender Komponenten oder Softwaresysteme sind diese auf Abhängigkeitsbeziehungen zwischen den Komponenten hin zu analysieren. Dann sind die alternativen Lösungsansätze anhand der erwarteten Beiträge zur Zielerreichung und möglicher Seiteneffekte auf andere Systemteile zu bewerten, um eine Entscheidung nach rationalen Gesichtspunkten treffen zu können. Diese Schritte (siehe die Zusammenfassung in Abbildung 1) folgen den Vorschlägen des Vorgehens zur Entscheidungsfindung aus der präskriptiven Entscheidungstheorie [EW03]. Abhängigkeiten zwischen Zielen, Rahmenbedingungen Entwicklung alternativer Lösungsansätze unter Berücksichtigung der Ziele, Rahmenbedingungen und den Beziehungen zwischen Architekturkomponenten Abhängigkeiten zwischen Architekturkomponenten Abbildung 1: Berücksichtigung der Abhängigkeitsbeziehungen bei der Entscheidungsfindung 2 Typen von Abhängigkeitsbeziehungen Abhängigkeitsbeziehungen spielen für das Verständnis von Zusammenhängen durch Architekten und Entwickler eine besonders wichtige Rolle. Sie werden für Aufstellung, Bewertung und Prüfung von Lösungsansätzen benötigt. Zu ihrer Modellierung und Beschreibung in verschiedenen Methoden der Softwaretechnik wurde eine Vielzahl verschiedener organisatorischen und technischen Abhängigkeitsbeziehungen verwendet, die teilweise unter verschiedenen Bezeichnungen geführt werden. Für ein einheitliches Verständnis wurde aus dieser Menge in Anlehnung an [KL05] eine für die Entscheidungsfindung relevante Auswahl von Typen getroffen (Tabelle 1). Eine Fokussierung auf wenige Beziehungstypen ist notwendig, um Abhängigkeiten besser analysieren und ihren Einfluss auf Entscheidungen bewerten zu können. Tabelle 1: Typen von Abhängigkeitsbeziehungen Beziehungen zwischen Komponenten Maßn. zur Architektur-Veränderung Ziele, Rahmenbedingungen Komponenten ‚bedingt durch‘ ‚benutzt von‘ ‚aggregiert mit‘ ‚spezialisiert zu‘ ‚Teil von‘ ‚in Konflikt mit‘ ‚erfüllen vollständig/ teilweise‘ Maßnahmen zur ArchitekturVeränderung ‚erzwingen‘ ‚in Konflikt mit‘ ‚zusammengefasst‘ ‚beeinflusst von‘ Ziele, Rahmenbedingungen ‚sich ergänzend‘ ‚miteinander konkurrierend‘ Die in Tabelle 1 aufgeführten Beziehungstypen beziehen sich auf folgende Elemente von Architekturentscheidungen (siehe Abbildung 1): Ziele und Rahmenbedingungen können sich ‚ergänzen‘, in einer Ziel-MittelBeziehung stehen, ‚konkurrieren‘ und sich gegenseitig ausschließen. In diesen Fällen muss ein Kompromiss gefunden werden. Beispiele: Budget-Restriktionen, Vorgaben hinsichtlich der zu verwendenden Frameworks. Architekturkomponenten können sich gegenseitig ‚benutzen‘ oder in einer ‚aggregiert mit‘ / ‚spezialisiert zu‘ Beziehung stehen. Diese Beziehungen geben wichtige Hinweise darauf, welche Komponenten unabhängig und welche Komponenten ausschließlich in Kombination verändert, ausgetauscht oder ergänzt werden können. Beispiele: Softwarekomponenten wie Broker, Event-Handler oder Datenbanken. Maßnahmen zur Veränderung der Architektur können miteinander ‚in Konflikt‘ stehen oder sich gegenseitig ‚erzwingen‘. Gerade umfassende Architekturveränderungen müssen aus Risiko-, Ressourcenund Steuerungsaspekten heraus in kleinen Schritten durchgeführt werden. Da zum Zeitpunkt der Entscheidung eine Sequenz oder eine Folge mehrerer Maßnahmen gleichzeitig zu berücksichtigen ist, ist die Kompatibilität der Maßnahmen zueinander sicherzustellen. Beispiele sind der Austausch, die Zusammenfassung oder die Teilung einer Komponente. 3 Systematische Berücksichtigung der Abhängigkeitsbeziehungen bei der Entscheidungsfindung Um die in Tabelle 1 dargestellten Beziehungen bei der Entscheidungsfindung zu berücksichtigen sind zunächst die Beziehungen zwischen den Zielen und Rahmenbedingungen und zwischen den Architekturkomponenten zu identifizieren. Zur Illustration werden hier Ausschnitte eines größeren Projektes angeführt, die eine Architektur-Veränderung am Web-Content-Management-System Typo3 behandeln. Typo3 ist eine Open Source PHP-Webapplikation zur Gestaltung und Konfiguration von komplexen Webseiten. Typo3 ist modular aufgebaut; neben einem Typo3-Kern existieren über 3.000 sogenannte Extensions, die einen Einsatz von Typo3 in vielen Anwendungsdomänen ermöglichen [FR05]. Widerspruchsfreie Strukturierung der Ziele und Rahmenbedingungen Zur Strukturierung ‚konkurrierender‘ oder ‚sich ergänzender‘ Ziele wird in der ersten Phase ein Ziel-Mittel-Diagramm erstellt. Das Vorgehen hierzu entstammt aus der Entscheidungstheorie [EW03]. Dabei werden die Ziele zerlegt, verfeinert, nach Instrumentalund Fundamentalzielen klassifiziert und in eine baumartige Ziel-Mittel-Struktur eingeordnet. An der Spitze stehen die Fundamentalziele, welche durch die verschiedenen Instrumentalziele verfeinert werden. Diese Art der Strukturierung der Ziele erleichtert die anschließende systematische Priorisierung der Ziele. Die Zerlegung wird fortgesetzt, bis jedes Ziel in eindeutigen Ziel-Mittel-Beziehungen zu den anderen Zielen steht. Im Beispiel Typo3 besteht das Ziel in einer Steigerung der Portabilität bezüglich des verwendeten Datenbank-Managementsystem DBMS. Ein zentraler Schwachpunkt von Version 3.6 ist die Bindung an das DBMS mySQL, was die Verwendung in einem Unternehmensumfeld stark einschränkt, weil hier häufig andere DBMS etabliert sind. Um als Fundamentalziel die Portabilität in der Version 4 zu verbessern, sind geeignete Lösungsansätze zur Restrukturierung des Datenbankzugriffs zu entwickeln und zu vergleichen (siehe Abbildung 2). Ein konkurrierendes Fundamentalziel sind die Antwortzeitverhalten. Da kurze Antwortzeiten für Typo3 ein kritischer Erfolgsfaktor sind, darf die Restrukturierung keinesfalls zu einer Verschlechterung führen. Eine Beeinträchtigung der Antwortzeiten ein hohes Risiko dar, da ein Wechsel zu einem anderen ContentManagement-System mit erheblichem Aufwand verbunden wäre.